1. Field of the Invention
The invention relates to telecommunications. In particular, the invention relates to a novel and improved method and system for routing data packets from a multihomed host.
2. Description of the Related Art
Communications networks, particularly packet switched data communication networks or packet data networks such as Internet Protocol (IP) based networks, typically comprise a number of nodes connected to each other by links.
The term ‘link’ refers to a communication facility or medium over which nodes can communicate at the Open Systems Interconnection (OSI) data link layer. Nodes are devices which typically implement Internet Protocol. A node that sends or originates data packets is known in the art as a ‘host’ or, more particularly, a sending host. Correspondingly, a node that receives data packets explicitly addressed to itself is also known in the art as a ‘host’ or, more particularly, a receiving host. The term ‘router’, on the other hand, refers to a node that forwards IP packets not explicitly addressed to itself. Furthermore, the router performs this forwarding on the Open Systems Interconnection network layer.
Thus, by using hosts and links, local networks may be arranged. A local network may be e.g. a Local Area Network (LAN). A local network may in turn be connected to another local network or to e.g. Internet by using a router.
Therefore, in order for a host in a given local network to be able to send or receive data packets outside of its local network, the local network needs to be linked to at least one router which is able to route data packets to and from outside the local network. In the context of the present invention, such a router is called a ‘gateway’.
Even though routers are the nodes responsible for actual routing in a network, a host typically also comprises a simple routing table. The routing table of a host is a look-up table which comprises routing entries which a sending host utilizes in determining where to dispatch a data packet to be sent to its destination. The data packet to be sent comprises a destination address, which typically is an Internet Protocol address of the destination of the data packet. The sending host goes through the routing entries comparing them to the destination address of the data packet to be sent, and looks for a routing entry that best matches the destination address of the data packet.
Typically some of the routing entries point to other hosts in the local network of the sending host, i.e. they define ‘host routes’. If the local network is a large one comprising locally linked subnetworks, some of the routing entries may point to these subnetworks, i.e. they define ‘subnet routes’. The sending host goes through its routing entries from the specific to the general. In other words, it first tries to find an exactly matching host route. If it cannot find an exactly matching host route, it then tries to find a matching subnet route, if the routing table includes them. In addition to the host routes and subnet routes, the routing table may comprise a routing entry which defines a ‘default route’. The default route is used as a last resort if no matching routing entry can be found. In other words, the default route is used if the host cannot locate the destination of the data packet at the local network of the host. The default route points to a router, called a ‘default gateway’, which is able to forward the data packet towards its destination address. Thus the default gateway is typically used in cases where the destination of the data packet is located outside of the local network, since typically the simple routing table of a host comprises routing entries related only to the local network of the host. If the routing table of a host does not comprise a default route and no matching routing entry can be found, the data packet to be sent is typically discarded.
Typically a host comprises one network interface which typically has one network address, such as an Internet Protocol address, associated with it. Each host is typically assigned a default gateway which is associated with the network interface of the host, or more particularly, with the associated network address of the network interface of the host. Information about the assigned default gateway is typically stored in the routing table of the host.
As described above, a host typically comprises one network interface with one associated network address. However, a host may comprise multiple network interfaces, each with their own associated non-loopback network address, such as a non-loopback Internet Protocol address. Furthermore, a host may comprise a network interface with multiple associated non-loopback network addresses, such as non-loopback Internet Protocol addresses. Such a host is known in the art as a ‘multihomed’ host. Typically, network interfaces of a multihomed host each interface to a different network. In such a case the multihomed host will have multiple network addresses on the different networks with different network prefixes.
As described above, a multihomed host has multiple non-loopback network addresses associated with it. Therefore, a receiving multihomed host may be reached under multiple network addresses. A network may be configured in such a way that data packets travel on physically different paths towards the receiving multihomed host depending on which of the multiple network addresses of the receiving multihomed host is used as the destination address of each data packet. Such an arrangement is typically used to protect against physical network failures and changing network conditions. Today multihoming is often used together with Stream Control Transmission Protocol (SCTP) which allows transmitting multiple streams of data at the same time between two hosts that have established a connection in a network.
Just as a receiving multihomed host may be reached under its multiple network addresses, a sending multihomed host may use one of its multiple network addresses as a source address for a data packet to be sent from the multihomed host. In a first arrangement, the source address is explicitly assigned, often by the application sending the data packet. In other words, the source address and the associated network interface of the multihomed host are known before the data packet is sent. In a second arrangement, the source address is unknown while the data packet is being sent. This is a typical case for a client requesting a service over a network. In the second arrangement, the source address is typically assigned after searching the routing table of the sending host. The search of the routing table of the sending host will return both information about the selected next-hop node and information regarding which of the network interfaces of the multihomed host is connected to the link to the selected next-hop node. The network address associated with this network interface will then be assigned as the source address of the data packet.
Although multihoming generally provides reasonable protection against physical network failures and changing network conditions, there still is a severe drawback with multihoming which relates to default gateways.
As described above, a routing table, whether that of a conventional host or of a multihomed host, comprises exactly one default route which points to exactly one default gateway. More particularly, the routing table comprises exactly one active default route. That is, although one typically can assign a different default gateway to each network interface of a host or each network address of the host, there is only a single active default route in the routing table of the host. Typically this single active default route points to one of the assigned different default gateways. In some cases, the one default gateway of the assigned different default gateways to which the active default route points to, is chosen randomly, e.g. while initializing the host and its Internet Protocol stack. This randomness may lead to confusion and loss of connectivity. Furthermore, in a case where a sending host comprises multiple network interfaces, only locally linked hosts and those non-locally linked hosts which are reachable by the active default gateway, may be reached by the sending host via any of its network interfaces.
Furthermore, since there is only a single default gateway assigned at any given time, this default gateway constitutes a potential single point of failure. That is, if anything happens to the default gateway, the entire routing arrangement fails.
Obviously, the existence of a potential single point of failure is something that must be avoided, particularly in fault tolerant systems, such as e.g. telecommunications networks. Likewise, a host communicating with multihoming Stream Control Transmission Protocol needs to avoid the existence of potential single points of failure.
Prior art includes some techniques which attempt to prevent a single default gateway of a multihomed host from becoming a single point of failure. However, these techniques have serious additional drawbacks of their own.
One such prior art technique is the use static routes in the routing table of a host. The term ‘static route’ refers to a route that is added manually to the routing table of the host. One may e.g. add a route pointing to a locally linked gateway other than an assigned active default gateway. In other words, this added static route is a ‘gateway route’. Furthermore, one may define the static gateway route so that data packets destined to a given network or group of networks will be dispatched from the sending host to this locally linked gateway. Obviously, one may add multiple static routes. Yet, there are severe drawbacks associated with the use of static routes. One such drawback is lack of scalability. Each time a new destination network needs to be made visible to existing hosts of a local network, it requires either a new static route to be added or using the default route. Therefore, establishing new destination networks may require configuring routing tables of each host of the local network. This, in turn, is a major drawback in case of large local networks. Furthermore, the larger the amount of manually maintained static routes, the larger the possibility of human errors.
However, a routing table of a host, including its static routes, may be configured and updated automatically by using dynamic routing protocols, such as Open Shortest Path First (OSPF) protocol. In this way, human errors are mostly eliminated. Yet, dynamic routing protocols have drawbacks of their own, particularly in cases where fault tolerance is required. For example, it takes a relatively long period of time to obtain the network topology at unit start-up phase, since information about the network topology is gathered from various routers around the network. In case of a fault tolerant service that time may cause a break in the service. Yet, particularly in extremely fault tolerant systems any breaks need to be avoided. Furthermore, running a dynamic routing daemon at a multihomed host complicates the configuration of the host. Furthermore, security and configuration problems may arise if the existing network topology needs to be more open. Furthermore, Internet Protocol Version 6 (IPv6) support for dynamic routing may be missing. Even though Internet Protocol Version 6 is a quite generally spread protocol, it is still an open question whether a fault tolerant service should be based on an Internet Protocol Version 6 based dynamic routing protocol, such as Open Shortest Path First Version 3 (OSPFv3).
Prior art further includes a solution introduced by Linux community, known as ‘Policy Routing’. Policy Routing provides a framework for a router in making a forwarding decision based on information other than the destination Internet Protocol address of a forwarded Internet Protocol packet, e.g. based on the source Internet Protocol address of the forwarded Internet Protocol packet, or a transport protocol port. In short, the Policy Routing consists of building up a database of active policy rules, prioritizing those rules, and describing an action matching a rule for an Internet Protocol packet to be routed. However, the implementation of the Policy Routing is a complex one: e.g. each policy rule may have a whole routing table of its own. Further information about Policy Routing is available e.g. on http://www.policyrouting.org.
Therefore, the object of the present invention is to alleviate the problems described above and to introduce a solution that allows routing data packets from a multihomed host in a way that allows multiple default gateways being utilized by the multihomed host.